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Iht  ala  of  the  work  presented  in  this  report  is  directed 
at  the  creation  of  an  apart  Srstea  which  can  act  as  a 
consultant  to  aid  the  finite  eleaent  analyst.  In  principle  the 
systea  oust  he  capable  of  assisting  the  FE  user  to  cover  the 
full  range  of  requireaants  froa  Initial  aodelling,  to  result 
interpretation  and  error  checking  and  should  be  capable  of 
advising  over  the  full  range  of  problea  types;  statics, 
dynaalcs,  coaposltes,  non-linear  analysis,  etc. 


The  incorporation  of  A.l.  techniques  into  the  engineering 
design  process  has  progressed  at  an  ever  increasing  pace  in 
recent  years.  Conferences  E13  have  been  devoted  to  this  aspect 
of  computer  based  design  and  at  least  me  systea  C23  has  been 
incorporated  into  the  preliainary  design  process.  Soae  of  this 
expertise  has  been  passed  across  to  the  finite  eleaent  world 
with  a  view  to  providing  consultancy  prograas  for  either 
assisting  with  the  aodelling  process  or  generating  a  computer 
based  'users  nanual ' .  The  aaln  approach  in  this  situation  has 
involved  the  use  of  existing  Expert  Systea  Shells  either 
constructed  froa  'eapted'  prograas  such  as  EXYCIN  [33  or 
specially  constructed  shells  as  SAVIOR  [*3. 

This  latter  approach  involving  the  use  of  existing  shell 
like  prograas  assuaes  that  the  knowledge  and  the  coaputer 
systems  designed  to  handle  it  can  be  completely  separated. 
There  is,  however,  evidence  froa  human  learning  studies  that  the 
aodelling  of  a  domain  contributes  strongly  to  the  problea 
solving  ability  and  the  flexibility  of  any  resulting 
inferenelng  systea.  Johnson  and  Thompson  [53  show  that  the 
consequences  of  Inadequate  knowledge  representation  in  both 
human  and  computer  problea  solving  gives  rise  to  a  performance 
which  has  the  false  appearance  of  success.  Sloaan  [63  supports 
this  concept  and  argues  cogently  against  the  advocates  of 
particular  foraallsas  for  representing  all  kinds  of  knowledge. 
It  can  he  deaonstrated  that  first  order  predicate  logic  aay  have 
an  laportant  role  in  theorising  about  intelligent  systeas  but  is 
limited  in  scope  and  range.  In  the  light  of  this  type  of 
argument  it  is  suggested  [63  that  different  formulations  are 
useful  for  different  purposes  to  cover  the  wide  variety  of  types 
of  espresslonal  systeas  used  by  people  in  different  fields  such 
as  mathematicians,  scientists  and  engineers. 
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arguments  point  away  froa  the  immediate  use  of  a 
it  for  any  finite  element  consultant  program .  A 
seems  to  lie  in  examining  the  nature  of  the 
basing  any  system  on  the  irhsrent  structure  of  the 
In  this  aay  any  'inference  engine'  can  then  be 
to  iaplemsnt  the  casual  sequences  inherent  in  the 
f  the  rule  base  employed  by  an  expert  practitioner, 
herein. 


The  need  for  tbs  application  of  A.l.  methodologies  to 
finite  element  analysis  is  growing  in  importance.  First  of 
all*  because  the  VS  systems  are  becoming  complex,  the 
asm  finite  element  specialist  finds  then  very  difficult  to  use. 


Secondly,  because  It  Is  now  widely  recognised  that  the  systems 
cannot  be  used  as  'black  boxes'  and  require  a  high  level  of 
experience  If  errors  are  to  be  avoided.  As  a  result  a  general 
assessment  engineer  cannot  examine  the  structural  Integrity  of 
an  item  or  component  using  the  finite  element  method  as  a 
non -special 1st  without  running  the  risk  of  making,  potentially, 
catastrophic  errors.  A  Successful  F.E.  Expert  8ystem  will 
return  the  FE  method  to  the  general  engineer  as  a  safe  and 
reliable  design  assessment  tool. 

Because  the  finite  eleme  method  has  a  vast  range  of 
applicability  the  starting  point  to  the  present  work  was  fixed 
as  the  static  analysis  of  linear  structures.  Having  limited  the 
scope  of  the  proposed  Experty  System  It  was  also  found  necessary 
to  limit  the  range  in  order  to  build  a  prototype  program. 
Prototyping  has  proved  to  be  beneficial  In  other  A.l.  projects 
and  was  felt  to  be  extremely  important  in  F.E.  analysis  Where 
there  is  a  complex  interaction  between  engineering  judgement  and 
firm  mathematical  knowledge.  Thus  a  very  limited  prototype 
program  has  been  constructed  and  is  outlined  below. 

The  main  activity  of  this  program  is  to  select  appropriate 
finite  elements  for  specific  structural  configurations.  It  is 
written  in  LI8P  as  initial  studies  indicated  that  the  list 
compiling  properties  of  the  language  could  be  used  to  advantage. 
The  outcome  of  the  work  does,  however,  point  strongly  to  some 
form  of  object  oriented  description  language  particularly  with 
respect  to  procedual  aspects.  Hi thin  this  framework  the  main 
influence  and  control  processes  could  be  efficiently  exploited. 

The  remaining  sections  of  this  report  described  the 
overall  problem  at  which  the  program  is  directed  and  the 
specific  sub-program  selected  for  prototyping.  An  outline 
description  of  the  program  architecture  is  presented  though 
aspects  related  to  usage  are  reported  separately.  Finally  the 
report  indicates  future  lines  of  progress  which  could  be 
implemented  with  a  view  to  generating  a  user  friendly  interface 
and  expert  advisor  to  major  finite  element  systems. 
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2.1  intraflucMan 

Mwn  the  finite  element  method  is  considered  and 
subsequently  used  for  the  analysis  of  a  major  structural  item  a 
range  of  problems  confront  the  engineer.  These  start  with 
overall  aspects  which  relate  to  planning  the  job  and  continue 
through  more  technically  specific  matters  such  as  meshing, 
element  selection  and  conclude  with  the  need  to  interprets  the 
results  with  respect  to  the  accuracy  of  stresses,  displacements, 
frequencies,  mods  shapes  etc.  The  questions  associated  with  FE 
applications  tend  to  be  the  same  in  nature  for  all  types  of 
apple iat ion.  Often  the  only  change  in  moving  from  one 
application  to  another  is  the  focus  of  the  question.  For 
example,  similar  questions  must  he  answered  if  elements  srs 
ha lng  selsetsd  for  static  and  dynamic  analyses  but  the  relative 
importance  changes  in  the  move  from  static  to  dynamic 
considerations .  In  attsepting  to  construct  an  Expert  System  it 


is,  therefore,  natural  to  define  the  problem  in  terms  of  the 
questions  which  must  he  answered  by  the  analysis.  In  this 
section  we  look  at  the  overall  problem  and  in  the  next  one  we 
address  the  items  specific  to  the  prototype  application. 

2.2  Problem  Description 

2.2.1  Rationale 

The  problem  of  analysing  a  structure  with  the  aid 
of  an  FE  system  is  described  below  in  terms  of  the  main 
areas  of  interest  together  with  an  Indication  of  some  of 
the  detail  considerations  which  fall  within  these  areas. 
As  indicated  earlier,  the  knowledge  required  for  the 
resolution  of  these  problem  areas  may  be  heuristic  or 
mathematical  in  nature.  Some  attempt  to  classify  the 
broad  nature  of  the  knowledge  is  given. 

2.2.2  Classification  (Outline) 

1.  Overall  Considerations  (Heuristic  Knowledge) 

i)  Planning  requirements  -  staff,  time-scales,  etc. 

ii)  Deciding  problem  type  -  static,  dynamic, 

non-linear  etc.  or  combination. 

ill)  General  suitability  of  FE  for  problem. 

lv)  Solution  requirements  -  hardware,  software. 

2.  Modelling  Problems  (Heuristic/Mathematical 

Knowledge ) 

1)  Main  structural  features 

-  shape  ( flat/ curved ) ,  thickness  of  members, 

curved/ straight  boundaries,  boundary 
constraints . 

11)  Materials 


isotropic,  anisotropic,  composites 
(orthotropic) . 

ill)  Responses 

-  linear,  non-linear,  dynamic,  etc. 
iv)  Loading 

-  static,  aerodynamic,  transient,  thermal,  shock, 
etc. 


v)  Structural  Inconsistencies 


joints,  off-sets,  discontinuities,  stress 
raisers,  contact  problems,  hinges,  etc. 

vi )  Damping  Type 

vii)  Structural /Loading  Symmetry  or  Asymmetry 

3.  Element  Selection  (Heuristic/Hathematical 

Knowledge ) 

i)  Structural  regions 

regions  with  similar  structural  properties 
identified 

i.e.  membranes,  beams,  shells,  etc. 
li)  Effect  of  material 

-  e.g.  'composite'  elements. 

lii)  Nodal  compatibility  or  M.P.C. 'a  required, 

iv)  Geometric  properties  accommodated 

-  curved  edges,  reinforcements,  off-sets,  etc. 

v)  Special  problems 

-  e.g.  shells. 

4.  Meshing _ Problems  (Heuristic/Hathematical 

Knowledge) 

1)  Grid  density  requirements. 

11)  Isoparametric  shape  restrictions. 

5.  Solution  Problems  (Mathematical  Knowledge) 

1)  Potential  numerical  Idealisation  problems. 

11)  Matrix  Inversion/solution  requirements, 
ill)  Eigenvalue /Vector  solvers, 
lv)  Non-linear  routines, 
v)  Reduction  methods. 


vi)  8ub-8trueture  considerations 
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6.  Results  Interpretation 

(Heuristic/Mathematical  Knowledge) 

i)  Equilibrium  checks 

-  nodal,  overall. 


li)  Consistency  checks 

-  Stress  jumps,  displacement  discontinuities,  etc. 
iii)  The  effects  of  structural  inconsistencies. 

It  should  be  emphasised  that  this  classification  is  not 
exhaustive  and  represents  an  outline  of  the  type  of  knowledge 
and  problems  found  in  finite  element  applications.  No  attempt 
has  been  made  to  augment  the  task  to  include  the  application  of 
pre-  and  post-processors,  nor  to  the  overall  design  problem 
which  would  require  consideration  being  given  to  automated 
design  methods. 


3.  CREATION  OF  FEES  (finite  element  expert  system) 

3.1  prototype  FhiiQgQPhv 

Although  it  is  tempting  to  use  am  established  shell  as  the 
basis  for  a  new  finite  element  Expert  System  the  arguments 
advanced  in  section  1  and  the  experience  gained  in  the  creation 
of  FEASA  C63  indicate  that  this  may  not  be  the  best  path.  A 
better  approach  is  to  create  an  Expert  System  based  on  the 
structure  of  the  finite  element  applications  knowledge. 
However,  the  creation  of  an  Expert  System  to  handle  the  full 
finite  element  analysis  problem  outlined  in  Section  2  represents 
a  formidable  task.  A  more  appropriate  line  of  attack  involves 
writing  a  prototype  Expert  System  based  on  a  limited  sub-set  of 
this  knowledge.  Specifically  the  items  in  2.2.2  under  Modelling 
Problem  1,  li  and  Element  Selection  i-iv  (inclusive)  were 
Included.  In  addition,  it  was  decided  that  only  statics 
problems  should  be  considered  at  this,  initial,  stage. 

Using  such  a  limited  sub-set  of  the  overall  FE  knowledge 
base  it  was  clear  that  no  meta-level  knowledge  or  control  was 
required.  But  the  augmentation  of  the  program  in  the  directions 
of  generality  would  soon  impose  such  a  requirement.  Thus  a 
modular  structure  for  the  Expert  System  architecture  was 
created.  For  convenience  and  portability  this  program  was  made 
specific  to  the  Digital  Equipment  Corporations  VAX  range  of 
computers. 
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No  Expert  System  can  be  made  independent  of  human  input 
nor  is  it  desirable  that  it  should  be  Independent.  Computers 
are  useful  for  certain  operations  and  engineers  are  more 
effective  in  other,  more  creative,  areas.  Any  Expert  System 
should  be  able  to  participate  in  a  dialogue  with  the  user.  In 
order  to  facilitate  this  man-machine  interaction  a  range  of 
FORTRAN  routines  have  been  created  to  allow  the  program  to 
exploit  the  screen  management  facilities  available  under  the 
VAX/VMS  4.2  operating  facility.  These  routines  also  serve  as 
the  main  control  program  for  the  Expert  System  as  a  whole. 

In  principle  there  is  no  need to  limit  the  range  of 
elements  which  can  be  included  in  FEES  and,  in  consequence, 
there  is  no  restraint  on  the  system  with  respect  to  potential 
interacing  FE  programs.  However,  because  special  problems  exist 
with  certain  complex  elements,  such  as  shells  etc.  it  was 
decided  for  convenience  to  limit  the  current  element  library  to 
simple  elements.  Because  this  is  not  a  fundamental  limitation 
the  library  can  be  augmented  when  deamed  suitable. 

3.2  EgES  Knowledge /Inference  Modules 

3.2.2  Overview 

When  the  finite  element  process  is  examined,  it  is 
found  possible  to  describe  the  basic  inference  process  as 
one  of,  essentially,  accumulating  constraints.  To  begin 
with  the  geometric  properties  of  the  structure  starts  a 
process  of  limiting  the  elements  which  can  be  used.  The 
concept  emmerging  from  this  limiting  process  is  that  the 
f  structure  to  be  analysed  needs  to  be  divided  up  into 

regions  with  similar  geometric  properties.  If  further 
limiting  factors  relating  to  the  structure,  such  as 
inconsistencies,  special  features  etc.,  are  included  it 
can  be  seen  that  there  are  a  range  of  constraints  which 
relate  to  the  structural  description.  With  these  limits 
in  place  it  is  possible  to  evaluate  appropriate  elements 
for  each  region  talcing  into  account  factors  such  as  nodal 
conformabillty.  Finally,  with  all  constraints  in  place 
and  the  evaluation  complete  the  process  of  selecting 
specific  elements  can  be  commenced. 

Clearly,  the  human  eye  is  more  appropriate  at 
deciding  if  a  structure  is  curved  or  thin  or  has  other 
important  geometric  properties.  Thus  the  FEES  program 
assumes  that  the  user  is  able  to  supply  this  type  of 
information  and  enters  a  dialogue  in  order  to  obtain  it. 

.  But  it  does,  currently,  assume  that  the  user  may  be  unsure 

1  about  the  types  of  mechanical  action  the  structure  is 

1  performing.  Thus,  during  the  dialogue,  the  user  is  asked 

to  place  a  level  of  certainty  on  such  factors  as  membrane 
action,  bending  etc. 


Purpose : 


to  describe  the  geometric  shape  of  the  structure 
and  material  properties  on  a  region  by  region  basis 

Mode  of  Action: 

1)  Divides  the  structure  into  regions  depending  upon 
the  basic  spatial  properties 

ii)  In  each  region  defines  structural  properties 
(curvature,  thickness,  boundaries) 

iii)  Identifies  special  regions  which  relate  to  beams, 
nodes  ets. 

iv)  Defines  material  properties  in  each  region 

v)  For  each  region  sets  up  an  element  identification 
'vector'  and  region  'vector'. 

These  'vectors'  are  predicate  type  descriptors 
encapsulating  the  properties  of  the  entities  under  consideration 
thus: 


REGION  <<>,<>,<>,(>> 

ELEMENT  (REGION,  PROPERTY,  MATERIAL, 

where 

REGION:  is  the  'vector'  describing  the  geometry  of 

the  structure  and  its  boundaries 


PROPERTY:  is  the  'vector'  describing  the  action 

property  of  an  clement,  i.e.  membrane, 
rod,  beam  . 


MATERIAL: 


relates  to  the  material  constants  and 
properties 


I 
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Each  of  these  defining  tenia  aay  have  a  list  of  arguments 
like  REGION,  for  exaaple,  MATERIAL,  includes  Poisson's  ratio, 
elasticity  constants  etc. 

2)  Eleaent  Evaluation  Module 
Purposes 

to  advise  the  systea  on  the  eleaent  properties 
required  for  each  region  such  that  the  Selector 
Module  can  atteapt  to  select  appropriate  eleaents. 

Mode  of  Actions 

1)  Augments  the  ELEMENT  list  with  further  constraints 
on  potential  eleaent  types 

ii)  Examines  each  region  to  decide  if  special  reasons 
exist  which  cut  down  the  available  choices,  i.e. 
shape  requireaents  (e.g.  the  incorporation  of 
curved  boundaries),  grading  requireaents  (e.g. 
local  stress  raisers  requiring  fine  aeshes),  etc. 

ill)  Examines  each  region  to  see  if  adjacent  regions 
impose  constraints  because  elements  have  already 
been  selected  there  (this  aay  Indicate  use  of 
M.P.C.'s) 

iv)  Special  loading  requireaents  aay  require  specific 
elements  or  the  structure  aay  require  special 
eleaents,  e.g.  presence  of  cracks. 

The  module  then  augments  the  EIJXENT  list  to  incorporate 
these  new  constraints  hence: 

ELEMENT  (REGION,  PROPERTY,  MATERIAL,  NODAL 
CONSTRAINTS,  SHAPE,  ETC....) 

where,  as  usual,  the  new  augments  aay  have  a  list  of  properties 
SIC; 

SHAPE  (BOUNDARY  SHAPE,  CURVATURE,  GRADING,  ETC.) 

MODAL  CONSTRAINTS 

(REGION,  ATTACHED  ELEMENTS,  GEOMETRIC 
CONSTRAINTS,  ETC). 


Soae  of  the  new  augments  can  take  account  of  any  special 
features  which  the  analyst  aay  feel  are  appropriate  to  eleaent 
selection.  For  exaaple,  not  using  a  3-D  membrane  eleaent  in  a 
Ming  Box  structure  Which  is  genuinely  3-D  whilst  the  aeabrane 
eleaent  is  really  only  2-D 


Purpose t 


to  use  the  accumulated  Information  from  the 
earlier  modules  to  select  elements  for  each  region 

Node  of  Action 

1)  For  each  region  unravels  the  ELEMENT  'vector'  and 
attempts  to  match  with  the  elements  in  the  library. 

4)  Additional  Module m 

Although  no  additional  modulus  have  currently  been 
incorporated  into  FEES  the  above  procedures  could 
be  extended  to  account  for  Meshing,  Loads,  etc. 

3.2.4 

The  structure  of  the  nodules  outlined  in  3.2.2 
Indicates  a  clear  pattern  to  the  way  the  knowledge  is 
accumulated.  Xf  this  is  compared  to  the  existing 
programing  languages  it  is  seen  that  both  LISP  and  PROLOG 
resemble  the  above  forms.  The  fact  that  one  of  the 
processes  involves  adding  facts  to  an  accumulating  list  of 
items  would  seem  to  point  towards  a  LISP  inplimentation. 
But  higher  order  lnferenclng  which  more  advanced  forms  of 
the  system  would  require  point  to  a  PROLOG  or  even  a  *C' 
impl lwentat ion .  However,  the  availability  of  DEC/LISP 

which  has  recently  been  Introduced  to  all  WAX  machines 
decided  the  issue  and  the  core  part  of  RE8  which 
implimenti  the  modulus  of  section  3.2.2  and  selects  the 
elements  is  written  in  DEC /LISP. 

As  explained  above,  the  control  modulus  which  call 
on  the  element  selector  routines  and  interface  with  the 
user  employ  PORTRAIT  or  VMS  routines. 

rm  irrMfrifityrt 


4.1 


The  program  is  constructed  in  the  usual  modular  fora 
adopted  by  all  modern  software  developments.  The  min 
components  consist  of  three  major  modules  described  in  3.2.2j 
the  structural  description  module,  the  element  evaluation  nodule 
and  the  element  selector.  Information  flew  and  overall  control 
are  achieved  through  the  control  nodule  whilst  the  uoer  operates 
the  system  through  the  input/output  module.  A  schematic  outline 
is  shown  in  Flg.l. 


At  the  pmtnt  ttM  tkm  U  no  epeclflc  4«Utm  though  * 
tatatoM  mi  ipproprUti  mnifint  ijritaa  will  ho  required  In 
future  as  the  teU  content  of  the  eye  ten  hullda  up. 

4.2  rmm, Wm, 

The  control  aeduls  canapes  the  flew  of  the  program 
arpanlalwf  teaks  such  that  each  activity  is  carried  out  at  its 
appropriate  tine.  If  the  ueer  asks  for  a  task  to  ho  port oread 
out  of  sequence  the  controller  overrides  and  indicates  ehat  the 
correct  scsssdurs  euoht  to  ho.  It  also  samaras  that  concurrent 
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In  Croatia*  tha  program  it  «m  necessary  to  start  th* 
tree*—  of  classifying  mi  defining  finite  elenont  'surface' 
and  ’Imp1  knowledge.  All  lull  to  the  erection  of  the 
•Inference*  Nodules  ehleh  hair*  a  clearly  defined  structure  of 
their  can.  he  a  result  It  is  apparent  that  the  handling  of 
finite  elsnsnt  knowledge  can  ho  hone  by  eon*  fora  of  Object 
Oriented  language.  Such  a  language  eeuld  be  uead  to  defin*  th* 
hnaeladfe  already  described  In  the  current  *  Inference*  Modulus 
and  any  future  extensions  corerinf  nor*  of  the  P.S.  prohlon.  In 
addition,  an  Object  Oriented  approach  eeuld  be  used  to  treat 
effect  in  the  Control  Nodule  as  part  of  a  Meta-level  reasoning 
ability. 

If  an  Object  Oriented  Approach  similar  to  the  C.M.L.  Ill 
language  is  adopted  than  a  link  mould  be  formed  with  existing 
Mature!  Language  programs  which  could  bo  employed  to  Croat*  a 
uoeful  tutorial  and  explanation  facility  for  nR.  Mi  thin  ouch 
a  tutorial  model  th*  ‘User  hssesor'  progran  would  be  located 
which  mould  asses  the  users  general  capability  and  knowledge  and 
automatically  adjuot  the  level  of  explanation  accordingly. 

hs  aeon  in  3.2.2  the  approach  adopted  in  the  development 
of  PULS  allow*  knowledge  and  constraints  to  be  put  together  in  a 
fora  which  can  be  easily  interpreted  as  instructions  for  a  User 
Nsnual.  thus,  the  resulting  K.S.  program  could  output  results 
In  a  fora  allowing  a  direct  input  to  HMTMM  (say)  and  thereby 
dispone*  with  aajor  parts  of  the  traditional  Users  Manual.  Ibis 
would  also  rsguire  tha  incorporation  of  graphics  facilities 
which  are  easily  achieved  in  this  type  of  approach. 

Finally,  the  structure  of  the  prototype  and  any  future 
successor  are  of  such  a  simple  fora  that  it  is  possible  to 
consider  ways  in  which  the  computer  itself  could  asses  a  given 
solution  run.  In  conssguoncs,  a  fora  of  learning  can  be  built 
Into  the  system  whereby  previous  runs  are  saaalnod  for  patterns 
of  usage.  Shis  would  hs  don*  in  gulet  periods  through  the 
development  of  an  interesting  program  called  'H— t* .  Ibis 
progran  would  cons  into  operation  when  fW  was  not  in  use, 
weuld  review  previous  runs,  and  attempt  to  assess  any  ueoago 
patterns  which  weuld  then  be  onpleywd  to  speed-up  future 
consultations. 
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Mho  ealsl Ins  nregren  eon  be  entondod  In  several 
directions  without  a  radical  re  organisation  in  th* 
felleoiag  areas i 
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ill)  Croatian  of  a  Oaor  Manual  raplaconant  nodula  to 
allow  for  tho  oaalor  uoo  of  NAP1MN,  WHIP,  ote. 

1*)  Llnhlnp  of  tho  propraa  to  a  perioral  finite  alanant 
rational  datahaao  to  lncraaao  the  ranpa  of 
potential  probleoe. 

ha  lndleatod  alaowhora  In  this  report  the  structure 

of  tha  hnowladoa  haso  ladlcatoa  that  an  opportunity  estate 
to  onplolt  on  Object  Oriented  Approach,  h  variety  of  0.0. 
Lanpuawes  are  avallohlo  hut  there  is  eone  advent  ape  in 
•oloetlnw  one  vhoro  the  dowel opnant  of  tho  lanpuepe  Itself 
eon  ho  hi  ended  Into  tho  dowel  epnent  of  the  knewledpe  hose 
and  Inference  onplno.  Ml  thin  this  franework  one 


pooalhllltv  la  to  onploy  tho  Conceptual  Medolllnp  Lanpuepe 
(C.N.L. )  holnp  developed  in  the  LORI  CS3  project  within 

the  Murepean  ■canonic  Connlttooe  WRIT  propranaee. 


Develc 


nte  could. 


ore,  take  place  In  the  followtnp 


1)  Wploitetion  of  C.N.L.  to  enhance  the  Control 
Module  facilities  and  to  he  tho  aaln  procedure  for 
doecrlhlnp  the  hnowledpe. 

11)  The  use  of  C.N.L.  to  create  a  wore  advanced  set  of 
roaeonlnp  facilities  both  at  tho  Neta-lowol  and 
lower  lovole  of  the  propraa. 
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rweUnf  a  specific  teclilcn  and  to  Instruct  the 
iwig.  A  ilifl*  Ht  of  'CMUd1  tests  and  HELP 
files  is  net  aieaat*  to  tkls  complex  task. 

11)  Coupled  with  the  hyl  snst  Ion /Tutorial  facilities  a 
'Oeer  Assessor  *  Is  required  to  allow  the  program  to 
cepe  with  users  she  are  aore  ignorant  of  the  finite 

elswsnt  nethod  and  Its  llaltatlon  than  they 

realise. 

5.2.4  OBMM£ 

As  Indicated  in  Section  5.1  It  Is  possible  to 
construct  a  program  uhlch  can  have  a  Halted  'learning' 
capability  built-up  f roe  runs  of  the  FBI  system.  The 
concept  uses  the  idea  that  each  run  of  the  systea  Is 
lopped  In  a  file  and  Is  than  available  for  analysis.  This 
analysis  Is  carried  out  by  a  new  propraa  called  Dreaaer 
which  examines  the  data  for  patterns  of  usage.  These 

patterns  can  then  he  used  to  prompt  users  towards  likely 
solutions  to  msohlnp  or  other  problems  when  a  new 
structure  is  being  set-up  for  T.Z.  analysis. 

It  is  felt  that  most  design  offices  do  have  their 
own  range  of  structural  analysis  problems  which  havs  a 
high  degree  of  similarity.  As  a  result  many  problems  will 
have  been  previously  confronted  and  the  P.E.  analyst  often 
starts  the  solution  process  using  this  'in-house' 
hnewledps.  Dreamer  Is  Intended  to  follow  the  same 
philosophy  and,  thus,  speed-up  the  lnferenclng  process. 
The  use  of  gulet  periods  on  the  computer  for  solution 
analysis  implies  that  the  Expert  System  will  appear  to 
'learn'  finite  element  knowledge  when  not  in  use  and  each 
consultation  should  seem  to  represent  an  improvement  on 
ths  previous  one. 
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A.l  INTRODUCTION 

The  FEES  program  described  in  this  appendix  is  a  prototype  program 
that  selects  the  best  elements  according  to  a  specified  set  of 
requirements.  The  user  selects  the  FE-package  to  be  used  and  then 
specifies  the  problem  to  be  modelled.  FEES  takes  the  element 
description  data  and  the  problem  specification  and  selects  the 
elements  which  best  satisfied  these. 

Great  emphasis  has  been  made  on  making  FEES  easy  to  use.  The  data 
input  is  free-format  and  it  is  performed  interactively  from  the 
terminal.  The  system  uses  the  Screen  Hanagement  Guidelines  (SMG) 
available  in  VAX/VMS  in  order  to  provide  a  "friendly"  environment  to 
work  with.  The  presentation  of  the  solutions  are  clear  and  self 
explanatory  and  enables  the  user  to  Interpret  the  results  vithout 
delay.  The  user  has  a  set  of  commands  which  allow  him  to  control  the 
consultation. 


A. 1.1  Facilities  in  FEES 

The  user  will  find  the  following  facilities  of  great  benefit  when 
using  the  system: 

1.  Flexible  data  input  by  the  user.  The  data  input  is  performed 
interactively  via  menu  windows.  For  each  menu  a  set  of 
specific  instructions  is  displayed  in  a  separate  vlndov. 
Further  help  can  be  obtained  with  the  HELP  comauind.  The 
options  done  in  a  menu  are  always  highlighted.  For  menu 
questions,  the  system  displays  a  small  counter  vindow  which 
indicates  the  number  of  questions,  the  number  ansvered,  and 
the  number  to  answer. 

2.  Solution  order.  A  typical  consultation  vlth  FEES  consists  in 
defining  the  FE- package  file  name  and  defining  the  problem  to 
be  medalled.  The  program  then  selects  the  best  elements  and 
displays  the  solution. 
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3.  Error  diagnostics.  FEES  checks  all  user  Input  and  the 
correct  evaluation  of  the  different  options  and  issues  the 
appropriate  error  Message  vhen  an  error  occurs. 

4.  User  interface  facility.  At  any  stage  during  the 
consultation  session,  FEES  can  be  instructed  by  the  use 
through  a  set  of  siaple  coaaand s  to  get  further  explanation 
on  the  current  Menu,  go  back  to  a  previous  aenu  etc. 


A. 1.2  Solutions 

FEES  has  been  developed  to  provide  solutions  for  the  eleaent  selection 
problea  vithin  FE  analysis  and  it  is  hoped  to  extend  the  present 
prototype  to  cover  a  auch  larger  part  of  this  field.  As  a  prototype 
It  has  been  verified  by  reference  to  worked  exaaples,  it  is  relatively 
easy  to  learn,  use  and  apply.  In  presenting  the  results  ve  have  tried 
to  provide  the  explanations  which  lie  behind  the  reasons  for  rejecting 
or  selecting  a  particular  eleaent. 


A. 2  USER  PROCEDURES 

This  section  describes  the  procedures  the  user  aust  follow  in  order  to 
eaploy  the  FEES  systea  together  vith  the  procedures  for  checking  input 
data  and  correcting  input  errors.  The  order  in  which  these  are  given 
approxiaates  the  order  in  which  a  FEES  consultation  proceeds. 


A. 2.1  Logging  in 

Make  sure  that  the  teminal  is  on  and  press  the  RETURN  key  one  or  nore 
tiaes  until  the  systea  proapts  to  you  for  your  user  nane,  type  in  your 
user  naae  and  press  the  RETURN  key.  The  systea  then  proapts  you  for 
your  passvord,  enter  your  password  and  press  the  RETURN  key. 


A. 2. 2  Accessing  the  FEES  prograa 

After  successfully  logging  In,  the  default  DCL  "$”  proapt  will  be 
shown  on  the  left  aargln  indicating  that  the  coaputer  is  ready  to 
accept  your  coaaands.  Type  the  FEES  coaaand  and  press  the  RETURN  key. 
This  coaaand  will  start  up  the  FEES  systea  by  loading  the  required 
files  (this  usually  takes  a  Minute  or  two  depending  on  the  load  on  the 
Machine)  and  displaying  the  FEBS  aaln  aenu  on  a  window  positioned  at 
about  the  centre  of  the  screen  (this  will  be  the  position  froa  which 
FEES  will  display  all  the  question  and  text  aenus)  together  vith  an 
instructions  vindov  positioned  at  the  bottoa  left  hand  corner  of  the 
screen  (this  will  be  the  position  which  FEES  uses  to  display  the 
instructions  for  every  question  or  text  aenu). 
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MOTE 

At  the  DCL  level  all  commands  given  to  the  computer 
must  be  followed  by  pressing  the  RETURN  key  to 
indicate  that  you  have  finished  typing  the  coaaand. 
Within  FEES  you  tell  the  system  that  you  finished  with 
a  menu  vhen  you  press  CTRL/ 2,  or  a  function  key 
command,  see  below. 


A. 2. 3  Consulting  FEES 

The  consultation  session  starts  by  asking  the  user  to  choose  one  of 
the  options  displayed  in  the  main  menu.  These  are  outlined  belov. 


A. 2. 3.1  OPTION  1.  Element  selection  -  This  option  allows  the  reading 

of  the  element  data  from  a  file  which  has  been  created  on  a  previous 

consultation  or  edited  separately.  A  further  menu  is  presented  here, 
vhose  main  purpose  is  to  define  the  element  data  to  be  used  by  FEES  in 
order  to  model  the  problem.  These  options  are: 

OPTION  1.  Lists  the  file  names  or  tables  which  contain  the 

element  data  in  the  format  needed  by  FEES.  Selecting  one  of  the 
names  restores  element  data,  if  a  nev  name  is  used,  a  new  table 
name  is  created. 

OPTION  2.  This  option  lists  the  element  names  knovn  to  FEES. 

OPTION  3.  Enables  the  user  to  viev  the  element  data  in  terms  of 

its  property  names  and  property  values. 

OPTION  4.  This  option  enables  the  user  to  add  (delete  or 

modify)  information  to  (from)  an  «ld  element. 

OPTION  3.  With  this  option  new  elements  can  be  added  to  FEES. 

OPTION  6.  Vhen  creating  or  modifying  an  element  the  property 

names  and  values  defined  must  be  knovn  to  FEES  thus,  this  option 
list  the  valid  names  and  values. 

OPTION  7.  Returns  the  user  to  the  main  menu. 


A.2.3.2  OPTION  2.  Problem  definition  -  With  this  option  FEES  is  told 
the  problem  to  model  by  answering  a  series  of  questions.  The  systems 
displays  previous  regions  which  may  be  selected  if  it  is  necessary  to 
restore  and  modify  a  previous  region.  If  one  of  the  names  is  selected 
or  a  new  one  Is  typed,  a  further  menu  is  displayed  with  a  series  of 
questions  to  be  answered  in  order  to  define  the  problem.  For  each 
question  several  answers  are  possible,  by  specifying  hov  certain  (or 
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important)  the  user  is  regarding  the  options  the  system  may  employ 
these  in  order  to  satisfy  the  user  requirements.  This  value  should  be 
given  as  a  percentage,  no  answer  or  0  being  don't  know,  100  being  for 
certainty,  50  for  not  too  sure  etc. 


A. 2. 3. 3  OPTION  3.  Element  selection  -  Here  the  program  evaluates  the 
ansvers  given  above  By  selecting  the  elements  which  best  match  the 
requirements.  The  screen  is  cleared  and  the  message  "LISP  WORKING." 
is  displayed  on  the  top  left  hand  corner  of  the  screen  (this  might 
take  a  few  minutes  depending  on  the  number  of  elements  and  regions 
used,  and  how  busy  the  machine  is).  When  finished,  the  main  menu  is 
re-displayed  with  the  option  to  view  the  valid  solutions. 


A. 2. 3. 4  OPTION  4.  Restart  a  consultation  -  This  option  allows  the 
user  to  restart  a  previously  SAV^Ed  session  so  as  to  modify  or  continue 
the  session.  The  system  displays  the  names  which  can  be  restored. 
The  name  typed  must  correspond  to  one  of  the  names  shovn. 


A. 2. 3. 5  OPTION  5.  Solutions  -  This  option  allows  the  solution  to  be 
viewed.  The  region  names  being  used  are  displayed  for  viewing  the 
solutions  individually.  The  combined  solutions  are  shovn  under  the 
name  "REGIONS". 

1.  RULE  1.  Eliminates  the  elements  which  have  nothing  in 
common  with  the  important  requirements.  i.e.,  All  the 
ansvers  greater  50  percent. 

2.  RULE  2.  Eliminates  the  elements  which  lacked  some  important 
requirements,  i.e..  The  ansvers  greater  50  percent. 

3.  RULE  3.  Eliminates  the  elements  vhich  had  all  the  essential 
requirements  but  missed  some  inessential  ones,  i.e.,  All  the 
ansvers  below  and  Including  50%.  The  don't  knows  and  0 
certainty  are  not  taken  into  consideration. 

The  final  solution  for  a  region  is  shovn  as  a  list  of  elements  vhich 
have  satisfied  all  the  important  and  essential  requirements. 

For  multiple  regions  the  valid  elements  and  the  ones  eliminated  by 
RULE  3  are  collected  and  RULE  4  rule  is  used.  This  rule  finds  the  bar 
and  membrane  elements  and  tries  to  match  the  nodes  at  the  boundaries. 
If  it  succeeds  it  shovs  the  results  as  a  list  of  bars  vith  the 
corresponding  aenbrane(s).  Elements  vhich  do  not  belong  to  these  tvo 
types  are  displayed  as  a  separate  list. 
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A. 2. 3. 6  OPTION  6.  Logoff  from  FEES  -  This  option  exits  the  user  from 
PEES.  The  screen  is  cleared  and  the  following  message  displayed 

End  of  consultation.  Back  to  LISP. 

Type  (EXIT)  to  exit  LISP  or  (RUN)  to  start  a  new  session. 

Lisp> 

To  the  LISP  prompt  "Lisp>"  type  the  desired  action. 


A. 2.4  Answering  questions 

The  actions  required  in  order  to  "make  the  system  do  things"  are 
follow: 

1.  Name  Question.  The  system  presents  the  question  to  the  user 
with  the  appropriate  instructions,  the  name  given  must  be 
alphanumeric  and  according  to  the  instructions  given.  Names 
are  typically  used  to  identify  an  element  or  a  file. 

2.  Numeric  Questions.  The  system  presents  the  question(s)  to 
the  user,  the  answer  given  must  be  within  a  valid  range  if 
not,  the  system  prints  an  error  message  notifying  what  went 
wrong. 

3.  Menu  Options.  The  answer  given  should  correspond  to  one  of 
the  options  displayed  in  the  menu.  If  the  answer  does  not 
match  any  of  the  options  then  an  error  message  is  displayed 
and  the  correct  option  should  be  typed. 

4.  Yes/No  Questions.  This  type  of  question  expects  a  yes  or  no 
for  an  answer  if  not,  the  system  prints  an  error  message. 
For  some  questions  a  default  answer  is  included  in  the 
question,  this  is  taken  if  no  answer  is  given. 


A. 2. 5  Finalizing  the  element  selection 

If  no  element  is  found  to  satisfy  all  the  important  and  inessential 
requirements  then,  use  can  be  made  of  one  of  the  elements  given  in  the 
list  provided  by  RULE  3  or  the  requirements  modified,  or  a  different 
F.E.  package  chosen.  On  the  other  hand  if  the  evaluation  is  found  to 
be  satisfactory,  a  new  session  can  be  started  with  the  restart  option 
or  logout  from  FEES  with  the  main  menu  options  4  or  6  respectively. 


A. 2. 6  Requesting  help  during  a  consultation  session 

At  any  point  during  a  consultation  session  the  user  can  find  the 
commands  available  to  him  through  the  INDEX  command  or  alternatively 
by  hitting  the  "PP4"  key. 
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A. 2. 7  Procedures  for  cheeking  and  correcting  Input  data 

According  to  the  type  of  question  the  system  checks  that  the  value 
given  corresponds  to  a  valid  input  format.  Numeric  questions  should 
be  within  a  valid  range,  for  yes/no  questions  the  answers  given  must 
be  YES  or  NO  (Y  or  N  for  short).  Finally,  there  are  menu  type  of 
questions  in  which  the  answer  given  must  be  one  or  more  of  the  choices 
displayed,  vhen  there  is  only  one  answer  this  is  made  explicit  in  the 
wording  of  the  question.  The  correction  of  input  data  is  made  easy  by 
having  the  system  display  the  error  thus,  the  user  can  edit  his 
ansver. 


A. 3  OPERATING  INSTRUCTIONS 

The  instructions  described  in  this  section  are  carried  out  in  order  to 
consult  the  FEES  system,  assuming  that  all  the  softvare  (LISP  version 
2  and  the  FEES  suite  programs,  text,  and  data)  and  hardware 
(e.g.  VAX-ll/VMS  version  4,  terminals  such  as  the  VT100  or  compatible) 
are  available.  The  instructions  described  here  include:  format  and 
content  of  each  input,  input  checks  that  are  made  by  the  system, 
action  taken  if  an  error  is  found. 


A. 3.1  Looking  at  error  messages 

Vhen  ansvering  questions  or  using  commands,  FEES  has  a  wide  range  of 
error  messages  in  order  to  provide  objective  information  about  the 
error.  The  system  displays  the  message  on  a  separate  window 
positioned  at  the  bottom  right  hand  corner,  this  window  is  removed 
when  the  answer  given  is  accepted.  Some  of  these  are: 

1.  Outside  of  range.  This  error  occurs  when  the  answer  given 
does  not  lie  vithin  a  valid  range. 

2.  Incorrect  choice.  When  the  ansver(s)  given  does  not  natch 
any  of  the  options  in  the  menu. 

3.  Invalid  ansver.  This  error  is  displayed  when  the  system  does 
not  understand  the  ansver  or  it  is  Invalid  vithin  the  present 
state  of  evaluation  of  the  session. 


A. 3. 2  Using  the  FEES  commands 

The  system  provides  four  basic  commands  which  can  be  Issued  at  any 
time  during  the  consultation  by  using  the  appropriate  PF  key  or  by 
typing  the  command  and  pressing  CTRL/Z.  These  are  (PF  key  and  vord): 


USER'S  GUIDE 


Page  A- 7 


1.  PF1  or  RPH 

This  coSund  returns  the  user  to  the  previous  aenu  vithout 
processing  any  of  the  answers  given  in  the  current  menu.  It 
is  useful  if  the  user  does  not  want  to  Bake  a  choice. 

2.  PF2  or  HELP 

This  coaaand  produces  help  text  on  the  current  aenu  in  the 
fora  of  definitions  and/or  example  answers. 

3.  PF3  or  SAVE 

This  coaaand  saves  the  state  of  the  consultation  and  logs  the 
user  off  from  FEES  returning  to  LISP. 

4.  PF4  or  INDEX 

ThelNDfeX  command  produces  this  help  text  on  the  commands 
available. 


A. 3.3  Instructions  for  answering  questions 

Every  question  and  text  aenu  in  FEES  displays  a  set  of  instructions 
aimed  at  helping  the  user  answer  and  read  a  piece  of  text.  The  aain 
types  of  display  are: 

1.  Menu  Questions.  These  type  of  questions  display  an 
enumerated  selection  of  possible  answers  from  vhich  the  user 
can  select  the  option  nuaber  and  attach  a  certainty  of  his 
answer.  Depending  on  the  question  single  or  aultiple  options 
can  be  chosen. 

2.  Menu  Options.  Menus  of  this  type  present  an  enumerated 
sequence  ol  the  possible  choices  and  the  ansver  given  should 
correspond  to  one  of  the  options. 

3.  Yes/Mo  Questions  Questions  of  these  type  are  used  to  confirm 
an  action  to  be  taken  step  before  proceeding.  Possible 
answers  are:  Y,  YES,  or  N,  NO.  For  this  type  of  question 
there  is  no  approxiaatlon  i.e.,  answers  like  "not  really”  or 
"unknown"  are  not  permitted. 

4.  Text  Menus.  These  type  of  menus  are  used  to  display 
inforaation  to  the  user. 


A. 3. 4  Logging  out 

When  the  session  at  the  terminal  is  final,  the  option  6  is  used  in  the 
PEES  aain  aenu  to  exit  returning  to  LISP  (the  proapt  "Lisp>"  is 
displayed)  then,  LISP  aacro  EXIT  is  used  to  return  to  DCL  coaaand 
level  (i.e.,  the  DCL  prompt  ”$”  is  displayed)  then  the  DCL  coaaand 
LOGOUT  ends  the  session.  The  system  responds  by  displaying  the  user 


tffMU  I 

rtoouuwn’s  tarot 


PBS  la  a  prototype  program  for  element  aaloctlon.  Thli  appendix  la 
ained  at  a  programmer  who  wishes  to  understand  RIS  In  order  to  ox t and 
It  or  Modify  it.  faaillarlty  with  USr,  POfeTIAN.  and  VAX/VMS  Scram 
Management  Guidelines  (SMG)  la  aaaunad .  The  appendix  la  concerned 
with  the  overall  atructura  of  the  program,  details  are  explained  in 
the  progran  coenants. 


g.i  omYiiv  op  ms 

There  are  two  najor  conponents  to  the  PXES  aysten.  These  are  the 
Man-Machine- Inter face  (MMX)  programs  and  the  element  selection 
programs. 


M.l.l  The  Man-Machine-Interface 

The  MMI  is  used  to  interact  with  the  user  by  obtaining  all  the 
required  input  and  displaying  the  results  found.  The  input  from  the 
user  is  translated  into  a  suitable  fora  for  the  element  selection 
program,  the  results  produced  by  the  latter  are  then  displayed  to  the 
user. 


1.1.2  The  element  selector 

The  element  selector  reads  the  element  description  data  and  "picks* 
the  elements  which  best  satisfy  the  user  requirements.  *  further 
selection  is  made  according  by  matching  the  nodes  between  elements. 


•.1.3  The  m$  source  files 

The  ms  system  is  made  up  of  a  set  of  LIST  and  MXTIM  programs,  and 
a  set  of  text  and  data  files.  These  aret 
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2.  UTMML.LV 

Definitions  of  thn  txltrul  POKTBAN  routines  wood  within 

uar. 

3.  n.LST 

Tko  controller  for  tho  intoroction  with  PUS. 

4.  LOAD. LSP 

Thin  filo  1*  wood  to  load  tho  different  LISP  source  file* 
required  hjr  PBS,  end  starts  up  tho  session. 

5.  NATdNOmS .  LSP 

The  controller  to  notch  nodes  between  different  regions. 


B.l.3.3  Till  files  -  A  set  of  files  is  used  by  the  POBTBAN  procedures 
to  proapt  tK  user,  it  also  provides  the  necessary  instructions  and 
help  text  to  answer  a  question  and  the  text  used  in  the  error 

passages. 


1.  file. MM 

The  aoau  files  are  based  on  the  philosophy  that  a  question 
consists  of  two  parts,  the  question  and  the  Instructions  on 
hew  to  answer.  Thus,  when  PISS  pronpt*  the  user  it  creates 
two  windows:  one  instruction  window  and  one  aanu  window  with 
a  'reeding  side"  where  the  user  can  type  an  answer  or  coaaand 
or  does  the  windows.  Bach  file  contains  the  instructions 
title  and  text  (3  lines)  followed  by  the  nenu  title  which 
panes  the  "parent"  nenu  and  text  (100  lines  aaxinus). 


2.  flle.MLP 

Siallarly,  the  help  files  consists  of  an  instructions  port 
|  and  a  text  pert.  Bach  aanu  has  a  help  text  file  associated 

with  it. 


3.  Mm.muoi 

This  is  a  single  file  which  stores  the  text  (3  lines)  used 
tdwn  an  input  has  occurred.  The  error  passages  are  displayed 
on  a  separated  wiadew  to  the  above. 


1. 1.3.4  BATA  files  -  Two  files  are  used  te  store  the  eleaent  property 
annas  and  preparty  values . 

1.  PPOPMtTT.BAT A 

This  filo  stares  the  property  aanes  and  values  known  to  the 
spataa.  It  is  need  te  provide  a  guideline  te  the  user  when 
defining  or  asdi tying  an  eleaaat . 

> 


1.  «MnW.MU 

Ikii  (11*  Unw  the  pttH't)  mm  and  nlMt  associated 
with  tit  MMtiM  wM  hy  the  systaa  Is  order  to  MIm  tk* 
pnhUs.  Tlw  seder  Is  which  they  sre  stored  relates  to  the 
order  si  the  sees  ti  ass  as  specified  is  the  fils 
^gdHTIOgg  •  KBWf®  • 

3.  file.hAT 

Stores  tbs  elenent  descript  too  date  ts  be  seed  by  tbs  elenent 
selector  pregran. 


t.2  usr  ruts 

■ere  we  eat  Use  the  overall  fusetios  of  tbe  USf  files,  since  a  sore 
detailed  description  css  he  fswnd  la  tbe  sewree  files  consents. 


>■2.1  Tbe  SlSIfT  SIUCTlOW.Uy  tile 

Tee  taper  tent  facilities  are  provided  by  this  file: 

1.  S  net  bed  for  retrieving  end  storing  the  elenent  description 

date. 

2.  A  net bed  of  ee lectins  as  elenent  given  sons  regui resents, 
providing  sens  enplane ties  when  ellninatlag  or  selecting  an 


S.2. 1.1  beading  tbe  olseeat  data  - 

This  procedure  is  used  to  read  the  data  free  the  file  fllMMB.  The 

elonsat  data  nest  be  stared  la  tbe  following  way: 

1.  The  first  record  indicates  tbe  nenber  of  eleaants  in  the 
file. 

2.  far  each  elanoat  description  the  following  order  is  taken: 

tha  elanoat  anas,  the  aanber  af  properties,  then  for  each 
property  there  is  associated  tbe  property  sane  and  its 

property  valee(s).  Vitb  the  last  record  af  the  elenent 
description  having  the  property  STOM-SCOtS  with  value  0. 

Tha  data  la  rood  ia  a  procedural  Banner  and  tbe  elenent  eases  are 

stored  ia  the  lint  BUNMT-MMS,  and  the  fallowing  two  precede  res  are 
aoad  to  organise  tha  data- 


»l|*  t-S 


Ikii  ptwfcw  li  tlM  w  »r>nny  list  InUitt  by  associating  Men 
•lasHt  with  a  mi  si  ycaysrty  mm  ank  wsIwm. 

— -wmn-uir  iwwn-uit) 

All  yrecekero  takas  a  yroyerty  list  as  iaywt  mi  (wtritti  a  saw 
aesyarty  list  besek  as  tbs  elk  asa  bat  ra-arSaraS  so  tkat  tka  yrsyarty 
ikMt  liters  ask  tkair  walae*  ara  is  alphabetical  arker. 


k.l.1.2  KlbSMt  selection  - 
■tMVT-SSLkCTlOM  (M610M,  F1UHMNR) 

Nt  sack  rag  1m  tka  hark  ask  salt  raaairaaaats  ara  aktaiaak  ask  tka 
alsBMts  ara  acarak  eccerkiagly.  Tkrsa  ralaa  ara  aaak  la  arkar  to 
alisiMta  tka  alaaaats  which  ka  sat  Mtisfiek  saaa  at  all  of  tka 
raaairaaaata.  Tka  results  ara  writtM  to  a  file  tar  latat 
casaaltatioa.  Tka  following  ara  tka  Min  yrocakuras  aaak: 

1.  BiaiMaoeiUD- nwrr -bata  (mmum  priority  i-moam) 

This  raw tine  rsaks  rasa Irak  a Isaac t  Rescript  ion  kata  as 
syecif ieb  by  tka  Mar.  FILMM  reyresents  tka  ration  mm 
ask  it  ia  aaak  to  writs  tka  quest  ions  (yroyerty  aasaa)  ashed 
to  tka  fila  "nUMAMK  OUKSTIONS.MPIOKT* .  PRIORITY  is  a 
striai  which  kaMtM  tha'cartaiaty  of  tka  aaawars  given  i.a., 
currMtly  100*  far  aaawars  batwaan  Si  ask  100  certainty 
walM.  ask  SOI  far  aaawars  batwaan  1  aak  SO.  Tka  I-PRIORITY 
is  tka  integer  valao  of  PRIORITY. 

2.  SC0R1-BACS-KUMNT 

Si  wan  tka  lafaraatiM  coctalnad  in  aokwlas  UAO-KLMBIT -DATA 
aak  RSAD-RnifltEll-RlJNRVr-DATA  this  aokulc  c  a  ay  sr  as  tka  kata 
la  tka  alaaant  property  list  (yllst)  aak  tka  required  kata 

r  royalty  list  aak  writes  tka  scars  in  tka  alaaant  yroyerty 
1st  Maker  tka  yroyerty  ikentity  SC0RR- STORE. 

3.  llUU-i  (PILBUM) 

This  is  as  tlsaent  select  ion  rule  which  states  tkat  if  an 
alaaant  in  the  kat  abase  koas  hot  Mtch  hay  of  tka 

ragalraaMta  ayaciflok,  wa  east  Ignore  it  for  tka  rest  af  tka 
na.  The  scores  af  Mch  slsswot  ara  ckackak  aak  if  they  ara 
saro  that  eleaMt  la  rMawak  froo  tka  list  ELRMRCT -NAMES. 
Tka  rejected  alaaant a  ara  aterek  la  a  llat  callek 

WU-l-BUfilfl.  FILENAME  is  tka  mm  of  tka  region ■  Tka 
rajactak  eleaMts  ara  written  to  tka  fila  "F11JNAME.RULE1” 
aak  the  aaawars  giwan  te  tka  fila  "FlUNIAIS_AltSVERS . MtMORT* . 

4.  MU-2  (FILENAME) 

This  la  m  alaaant  MlectlM  rule  which  states  that  if  an 
alaaMt  ia  tka  katabaaa  kaas  not  Mtch  all  of  the  essential 
regal resents  syaclflak,  wa  aast  Ignore  it  far  tka  rest  of 
this  na.  The  scares  af  each  el  ease  t  are  check ok  aak  if  they 
ara  lees  than  NAB  (aasiana  scare  far  a  givM  regvireaent) 

tkat  alaaMt  is  teaowek  fra*  tka  Hat  ItlWWT  HAWES.  The 

rajactak  eleaMts  ara  aterek  ia  a  Hat  callsk  EWLt-2 -DISCARD 


together  with  the  Maker  ot  alsaiai  properties.  FILENAME  is 
the  warn  at  the  region.  The  rejected  eleaents  ere  written  to 
the  file  "FIIENA  HE.EULE2"  end  the  answers  given  to  the  file 

S.  MLB- 3  (nUWB) 

This  la  an  eleaant  eelectlon  rule  which  states  that  If  an 
elaaaat  la  the  database  dees  not  natch  all  the  requlraaents 
specif led,  we  east  Ignore  it  for  the  rest  of  this  run.  The 
scares  of  each  eleaant  era  checked  and  if  they  ere  less  than 
■AIR  that  e lease t  is  raaoved  free  the  list  ELEMENT -NAMES. 
The  rejected  eleaents  ere  stored  In  e  list  celled 
RULE-3-D1SCARD  together  with  the  nuaber  of  aisslng 
properties.  The  rejected  eleaents  ere  written  to  the  file 
"FILENAME. RULE3*  and  the  answers  given  to  the  file 
"FIUNANEARSUERS .  MEMORY" . 

1.  acORB-RACS-RLENRNT 

given  the  inforest  ion  reed  by  nodules  READ-ELEMENT -BATA  and 
READ- REQUIRED- ELEMENT- DATA  this  nodule  coapares  the  data  In 
the  eleaant  pilot  and  the  required  data  pllst  and  writes  the 
acere  is  the  eleaant  pllst  under  the  property  none 
SCORE- STORE. 

7.  OUTPUT -ELEMENT -HAMS  (PILEHAME  R  I) 

This  routine  writes  the  valid  eleaents  to  e  file  FILENAME 
(region  nans)  after  RULE-1  and  RULE-2  and  then  after  RULE-3, 
creating  the  files  "FILENAME  1.0UT"  end  "FILENAME  2. OUT" 
respectively. 

R.  Finally,  the  results  (the  valid  eleaant  naaes)  ere  written  to 
the  file  "FILENAME. SOLUTIONS”  where  FILENAME  denotes  the 
region  wane. 


B.2.2  The  MATCH  HOME. LET  file 
NATCH-MOOS- BETWEEN- ELEMENTS  (REGIONS) 

Men  there  ere  ante  than  two  regions,  e  further  reduction  In  the 
nuaber  of  eleaents  Is  node  by  taking  the  list  of  eleaents  ellainatad 
by  RULE-3  and  the  valid  eleaents  for  each  region  end  then  notching  the 
nodes  at  the  boundaries.  The  following  ere  the  nein  procedures  used: 

1.  READ-REGIONS- ELEMENT-NAMES 

This  procedure  reeds  the  eleaant  naaes  for  the  different 
REGIONS  frea  the  file  FILENAME. RULE 3  and  FILENAME  2. OUT  where 
FILENAME  is  the  ease  of  e  region  In  REGIONS,  and  puts  then  in 
the  Hat  EUMRT-NAMS. 

.  RULE-4  (FILENAME) 

This  Is  an  eleaant  eelectlon  rule  which  states  that  if  two 
eleaents  of  type  her  and  aoahrane  in  the  database  are  not 
csapatible  at  the  nodes  they  oust  be  Ignored  for  the  rest  of 
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the  run.  Other  eleeents  which  ere  not  iaaediatly  aeen  aa 
incompatible  are  stored  in  LIST-OP-OTHER.  The  rejected 
elements  are  stored  in  a  list  called  RULE-4-D1SCARD  i.e.,  bar 
eleeents  for  which  there  are  no  watching  eeabrane  eleeents. 
FILENAME  is  the  nane  of  the  file  "REGIONS*.  The  rejected 
eleeents  are  written  to  the  file  " REGIONS. RULE4". 

3.  OUTPUT -REGIONS-ELEMENT -NAMES  (FILENAME) 

The  list  ELEMENT -NAMES  of  valid  eleeents  is  written  to  the 
file  "REGIONS. OUT*. 

4.  Finally,  the  results  (the  list  of  valid  eleeents  and  the 
eleeents  for  which  RULE-4  does  not  apply)  are  written  to  the 
file  "REGIONS. SOLUTIONS". 


>2.3  The  EXTERNAL. LSP  file 

Because  of  the  nature  of  LISP,  explicit  declarations  of  the  external 
routines  used  have  to  be  Bade,  see  VAX -LISP  user  annual.  These  are 
(equivalent  forest): 

1.  PRES  (REGIONS,  FILENAME,  ORDER-FLAG) 

This  routine  gets  the  input  froe  the  user  and  it  then 

displays  the  solution  file.  REGIONS  is  a  string  of  the  fore 
"REG  REG1  ...  etc",  FILENAME  is  a  string  of  the  fore 

"LUSAS.DAT" ,  and  ORDER-FLAG  is  an  Integer  which  Indicates  the 
state  of  the  consultation  i.e.,  exit,  solution,  or 
evaluation. 

2.  INTERPRETER  1  (FILENAME) 

This  routine  reads  the  solutions  data  files  and  forests  thee 
Into  a  readable  fora  explaining  the  Bean lng  of  the  data. 

FILENAME  is  a  string  denoting  the  region  naae.  This  routine 
creates  the  solution  file  "REGION. SOLUTIONS"  for  each  region. 

3.  INTERPRETER!  (FILENAME) 

This  routine  reads  the  solutions  data  files  and  forests  then 
into  a  readable  fore  explaining  the  weaning  of  the  data. 

FILBUNE  is  a  string  denoting  all  the  regions  used.  This 
routine  creates  the  solution  file  "REGIONS. SOLUTIONS”, 

4.  MNORIZE  (FILENAME,  MEMORY-NODE,  ORDER-NUMBER) 

This  routine  collects  all  the  output  froe  a  selection  run  and 
stores  it  in  the  nenory  file.  Each  piece  of  data  is  tagged 
with  date,  tine  ,  quantity  and  type  information.  FILENAME  is 
the  region  naae,  MEMORY-NODE  Is  a  string  nuaber,  and  the 
ORDER-NUMBER  is  an  Integer. 

1 

i 
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B.2.4  The  FE.LSP  file 

This  is  the  controller  for  the  interaction  with  FEES.  It  initializes 
some  data  and  calls  the  external  procedure  FEES,  according  to  the  user 
specification  it  evaluates  the  ELEMENT-SELECTION  or  exits.  After 
evaluation  the  external  procedure  PEES  is  called  in  order  to  observe 
the  results,  re-evaluate  the  answers,  or  exit  from  FEES. 


B.3  FORTRAN  FILES 


Several  files  have  been  written  in  FORTRAN  to  build  the  MM1  side  of 
the  systea  using  the  SHG  facilities.  Here  ve  outline  each  file,  with 
a  aore  detail  description  in  the  source  files  comments. 


B.3.1  The  ELEMENT  DATA -FOR  file 

This  file  defines  the  routine  ELEHENT_DATA  vhlch  reads  from  or  vrites 
to  a  file  the  element  naaes,  proper ty"naaes  and  property  values. 

FORMAT 

ELEMENT  DATA  (10,  IN  FILE,  NO  OF_ELEMENTS,  ELEMENT  NAME, 
NOOPPROPERTIES,  PR0PERTYJ1AMES,  PROPERTY" VALUES) 

ARGUMENTS 

10  >  integer  to  indicate  read  or  vrite- 

IN_FILE  >  input  string;  indicates  the  name  of  the  FE-package  name. 

NO_OF  ELEMENTS  »  output  integer;  indicates  the  nuaber  of  eleaents  in 
the  file  (maximum  100). 

ELEMENTNAME  >  output  string  vector;  stores  the  eleaenet  naaes. 

NOOPPROPERTIES  -  output  integer  vector;  stores  the  nuaber  of 
properties  for  each  eleaent  (aaxiaua  20). 

PROPERTY  NAMES  >  output  2D  string  array;  stores  the  property  name  for 
an  eleaent. 

PROPERTY  VALUES  *  output  2D  string  arrsy;  stores  the  property  values 
for  an  eleaent  property. 


B.3. 2  The  ERROR. FOR  file 

This  file  defines  the  routine  ERROR  vhlch  prints  the  error  aessage  by 
looking  for  the  error  type  in  the  file  DIR  ERROR: ERROR. MESSAGES.  It 
rings  the  bell  three  tiaes  before  printing  tSe  error  aessage. 
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FORMAT 

ERROR  (PB,  VD3,  ERRORTTPE) 

ARGUMENTS 

PB  >  input  integer;  denotes  the  pasteboard  identification. 

VD3  •  input  integer;  denotes  the  virtual  display  for  the  error  window. 
ERROR_TTPE  •  input  string;  denotes  the  error  type. 


B. 3.3  The  EXTERNAL. FOR 

This  file  defines  the  three  routines  used  within  LISP  to  format  the 
results. 

1.  INTERPRETER^ .  This  routine  creates  a  solution  file  of  the 
for  "REGION. SOLUTIONS"  for  each  region  REGION.  It  Interprets 
the  results  of  rules  1,  2,  and  3  and  gives  the  final  solution 
as  a  list  of  valid  elements. 

FORMAT 

INTERPRETER!  (REGION) 

PARAMETERS 

REGION  >  input  string;  specifies  the  region  name. 

2.  INTERPRETER_2 .  This  routine  interprets  the  results  for  two 
or  more  regions  by  writting  the  solution  to  the  file 
"REGIONS. SOLUTIONS".  (The  name  REGIONS  is  used). 

FORMAT 

INTERPRETER2  (REGIONS) 

PARAMETERS 

REGIONS  -  input  string;  specifies  the  list  of  regions. 

3.  MEMORIZE.  This  routine  writes  to  a  file  the  location  and 
time  at  which  the  questions  and  answers  were  processed. 

FORMAT 

MEMORIZE  (FILENAME,  MEM0R?_N0DE ,  ORDERCODE) 

PARAMETERS 

FILENAME  ■  input  string;  specifies  the  region  naae. 
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MEMORY  NODE  «  input  string;  specifies  the  filename  to  which 
questions  ("REG  QUESTIONS. MEMORIZE")  and  answers 
("REG_ANSVERS. MEMORISE")  are  stored. 

ORDER_CODE  «  input  integer;  specifies  solution  order. 


B.3.4  The  FEES. FOR  file 

This  file  defines  the  procedure  FEES  which  controls  the  interaction 
with  the  user.  The  procedure  is  called  from  LISP  and  it  is  used  to 
obtain  and  display  results  to  the  user.  FEES  erases  the  screen, 
creates  the  instructions,  menu,  and  error  windows  then,  displays  the 
■ain  menu  text.  The  procedure  actions  in  this  menu  are: 

OPTION  1.  Calls  the  routine  GET_FE_FILE. 

OPTION  2.  Calls  the  routine  GETREGIONS. 

OPTION  3.  Exits  from  this  procedure  and  returns  to  LISP, 
allowing  the  element  selection  to  be  performed. 

OPTION  4.  Calls  the  routine  SESSION. 

OPTION  5.  Calls  the  routine  SOLUTIONS. 

OPTION  6.  Exists  from  this  procedure  and  returns  to  LISP. 

FORMAT 

PEES  (REGIONS,  FEFILE,  ORDERFLAG) 

ARGUMENTS 

REGIONS  ■  input/output  string;  specifies  the  regions  used. 

FE_FILE  -  input/output  string;  specifies  the  FE  package  used. 

ORDER  FLAG  «  input/output  integer;  specifies  the  current  state  of  the 
consultation.  Valid  values  are  as  follows: 

0  output  integer;  if  consultation  is  to  be  terminated. 

1  input/output  integer;  if  FEES  is  to  request  the  user  the 
PEFILE  and  the  REGIONS. 

2  input  Integer;  specifies  that  the  element  selection  has  been 
completed  and  that  the  solutions  can  be  viewed. 


B.3.5  The  GET  FE  FILE  file 

nils  file  defines  the  routine  GET_FE_FILE  to  request  the  table  name 
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from  the  user  in  order  to  read  the  element  description  data  in  terms 
of  the  number  of  elements,  property  names  and  values,  it  also  allows 
the  user  to  define  nev  elements,  or  modify  existing  ones. 

FORMAT 

GET_FE_FILE  (PB_INFO,  FE_FILE ,  0LD_FILE,  0PTI0NJ50NE,  COHMAND_FLAG ) 
ARGUMENTS 

PB_INFO  =  input  integer  vector  containing  the  display  information. 

FE_FILE  =  output  string  denoting  a  previous  or  a  new  FE-file. 

OLD_FILE  =  output  string  denoting  a  previous  FE-file. 

OPTION_DONE  =  output  integer  vector;  indicates  the  options  selected  by 
the  user. 

COMMAND_FLAG  =  output  integer;  indicates  the  successful  completion  of 
this  routine. 


B.3.6  The  GET  REGIONS  file 

This  routine  asks  for  a  R£GION_NAME  then  it  calls  GET_TRUTH  and  saves 
the  answers  given  in  the  file  "REGION_NAME. REGION" . 

FORMAT 

GETREGIONS  (PBINFO,  REGIONS,  REGIONFLAG,  COMMAND_FLAG ) 

ARGUMENTS 

PB_INFO  «  input  integer  vector  with  the  display  information. 

REGIONS  -  output  string  denoting  the  list  of  regions  selected  by  the 
user. 

REGION_FLAG  -  output  integer  vector  denoting  the  state  of  each  region 
(maximum  of  10). 

COMMAND_FLAG  •  output  integer  used  to  denote  any  command  given  by  the 
user. 


B.3.7  The  GET  TRUTH. FOR  file 

This  file  defines  the  routine  GET  TRUTH  which  asks  several  questions 
to  the  user  in  order  to  define  tEe  problem.  On  successful  completion 
it  creates  two  files  REG  100. REQ  and  REG_50.REQ  vhere  REG  is  the 
region  name  and  the  100  and  SO  denote  The  certainty  of  the  answers 
given  i.e.,  all  the  answers  between  SI  and  100  are  stored  in  the  file 


PROGRAMMER'S  GUIDE 


Page  B-12 


REG_100.REQ  while  the  answers  between  1  and  SO  are  stored  in  the  file 
REG~50.REQ.  0  answers  and  no  answers  are  taken  as  don't  knows.  (For 
the'property  OUTPUT  any  answer  given  defaults  to  SOX  certainty). 

FORMAT 

GET  TRUTH  (PBINFO,  REGION  NAME,  NOOFQUESTIONS,  LINK  LINE,  REPLY, 
COMMAND_PLAG ,  TRUTH_PLAG)  ~ 

ARGUMENTS 

PB_INFO  «  input  integer  vector  containing  the  display  information. 

REGION_NAME  »  input  string  denoting  the  region  name. 

NO_OF  QUESTIONS  «  input/output  integer  denoting  the  number  of 
questions. 

LINK_LINE  =  input/output  integer  vector  denoting  the  position  of  the 
questions  in  the  text  file. 

REPLY  •  input/output  string  vector  denoting  the  answers  given  by  the 
user. 

COMMAND_FLAG  »  output  integer;  denotes  any  user  command. 

TRUTH_FLAG  «  output  integer;  denotes  the  successful  completion  of  this 
routine. 


B.3.8  The  HELP. FOR  file 

This  file  defines  the  HELP  routine  which  prints  help  text  on  the 
current  menu.  It  creates  a  smaller  window  than  the  FEES  menu  window 
which  contains  the  'help'  text  and  is  deleted  returning  to  the  menu 
window. 

FORMAT 

HELP  (PBINFO,  INFILE) 

ARGUMENTS 

PB_INFO  -  input  integer  vector;  contains  the  display  information. 

IN  FILE  «  input  string;  specifies  the  menu  file  (the  question)  for 
which  help  is  required. 


B.3.9  The  SOLUTIONS. FOR  file 


This  file  defines  the  routine  SOLUTIONS  used  to  view  the  individual 
regions  solutions.  It  displays  the  regions  for  selection,  vhen  more 
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than  one  region  exists  the  nane  "REGIONS"  is  also  included.  The  user 
selects  one,  and  the  procedure  VIEW  TEXT  is  called. 

PORMAT 

SOLUTIONS  (PBINFO,  REGIONS) 

ARGUMENTS 

PB_INFO  =  input  integer  vector?  contains  the  display  information. 
REGIONS  =  input  string;  specifies  the  region  name(s). 


B.3.10  The  UTILITIES. FOR  file 

This  file  defines  various  general  purpose  routines  for  string 
handling,  input  checking  etc.  The  routines  are: 

1.  CHECK.  This  routine  counts  the  number  of  characters 

according  to  their  type. 

FORMAT 

CHECK  (STRING,  L,  NOOFBLANKS ,  NO  OF  DECIMALS, 
NO  OF  ILLEGALS,  NO_OF_LETTERS , ~NO J)F_MINUS ,  NOOpNUMBERS ) 

ARGUMENTS 

STRING  »  input  string. 

L  »  output  integer;  denotes  the  length  of  the  string. 

The  rest  of  the  arguments  are  output  integers,  their  name 
denotes  their  type. 

2.  CHECK  NAME.  This  routine  checks  that  a  string  is 

alphanumeric. 

FORMAT 

CHECK_NAME  (STRING,  REASK) 

ARGUMENTS 

STRING  »  input  string. 

REASK  •  output  integer;  denotes  if  the  string  is  alphanumeric 
or  no. 

3.  CHECK  YESNQ.  This  routine  checks  that  a  string  is  a  yes  or 
no  answer. 


FORMAT 
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CHECK  YESNO  (STRING,  REASK) 

ARGUMENTS 

STRING  «  input  string. 

REASK  «  output  integer;  denotes  if  the  string  is  one  of: 
YES,  Y  or  NO,  N. 

4.  CLEAR.  This  routine  initializes  a  string  vector  to  eapty. 
FORMAT 

CLEAR  (LINE,  LINES) 

ARGUMENTS 

LINE  *  input  string  vector. 

LINES  «  input  integer;  denotes  the  number  of  lines  in  the 
vector. 

5.  COUNT  ITEMS.  This  routine  counts  the  number  of  items  in  a 
string  (assume  one  or  blanks  betveen  them) ,  and  returns  the 
items  in  a  vector  and  the  number  of  items. 

FORMAT 

COUNTITEMS  (STRING,  LINE,  LINES) 

ARGUMENTS 

STRING  -  input  string. 

LINE  «  output  string  vector. 

LINES  a  output  integer. 

6.  CSORT.  This  routine  sorts  a  list  of  words  in  dictionary 
order  using  a  simple  insertion  sort  technique. 

FORMAT 

CSORT  (LINE,  LINES) 

ARGUMENTS 

LINE  >  input/output  string  vector. 

LINES  a  input/output  integer. 

7.  C  TO  I.  This  routine  converts  a  string  number  to  integer. 
FORMAT 
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C_TO_I  (STRING,  N) 

ARGUMENTS 

STRING  -  Input  string. 

N  «  output  integer. 

8.  DIR.  This  routine  formats  a  string  vector  in  a  "directory" 
{ora. 

FORMAT 

DIR  (WIDTH,  COUNT,  LINE,  LINES) 

ARGUMENTS 

WIDTH  «  input  integer;  specifies  the  line  vidth. 

COUNT  «  input  integer;  specifies  the  nuaber  of  items  per 
line. 

LINE  »  input/output  string  vector  with  the 
individual/arranged  items. 

LINES  «  input/output  integer  representing  the  number  of 
lines. 

9.  GET  FILES.  This  routine  returns  in  a  vector  form  the  files 
tound  according  to  a  certain  specification. 

FORMAT 

GETFILES  (INFILE,  LINE,  LINES) 

ARGUMENTS 

IN  FILE  •  input  string  representing  the  filename(s)  to  look 
for. 

LINE  »  output  string  vector  representing  the  files  found. 

LINES  •  output  integer  representing  the  number  of  files 
found. 

10.  I  TO  C.  This  routine  converts  an  integer  to  a  string. 

FORMAT 

IJTOC  (N,  STRING,  L) 

ARGUMENTS 
N  -  input  Integer. 
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STRING  ■  output  string. 

L  -  output  integer  representing  the  length  of  STRING. 

11.  LOCATE.  This  routine  finds  the  position  of  an  itea  in  a 
string. 

PORMAT 

LOCATE  (STRING,  N,  TAIL,  L) 

ARGUMENTS 

STRING  •  input  string. 

N  •  input  integer  representing  the  position  of  the  iten  to  be 
found . 

TAIL  -  output  string  representing  the  truncated  string  vith 
the  "head"  as  the  itea. 

L  •  output  integer  representing  the  length  of  the  itea  (0  if 
not  found). 

12.  MEMBER.  This  routine  looks  for  an  eleaent  in  a  string  and 
returns  its  position. 

PORMAT 

MEMBER  (STRING,  LIST,  N) 

ARGUMENTS 

STRING  «  input  string  representing  the  iten  to  be  found. 

LIST  »  input  string. 

N  -  output  integer  representing  the  position  of  the  itea  (0 
if  not  found). 

13.  TRIM  OFF.  This  routine  tries  off  the  trailing  and  leading 
edge  blanks  fron  a  string. 

FORMAT 

TRIM_0FF  (STRING,  L) 

ARGUMENTS 

STRING  »  input/output  string. 

L  -  output  integer  representing  the  "true”  length  of  the 
string. 
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1.3.11  The  SMC  ROUTINES.  FOR  tilt 

This  fU«  defines  various  routines  which  are  used  to  handle  the 
input/output  with  the  user. 

1.  1IGBLIGRT  OmOH,  This  routine  it  used  to  highlight  the 
options  of  a  aenu. 

FORMAT 

HIGHLIGHT  OPTION  (VO,  LINE,  LINES,  OPTION  DONE, 
NOOFOPTlONS) 

ARGUMENTS 

VD  -  input  Integer;  specifies  the  display  identification. 

LINE  •  input  string  vector;  represents  the  aenu  lines. 

LINES  »  input  integer;  represents  the  nuaber  of  lines  in  the 
aenu. 

OPTION  DONE  »  input  integer  vector;  represents  the  options  to 
highlight. 

NOOFOPTlONS  -  input  Integer;  represents  the  nuaber  of 
options  in  the  aenu. 

2.  KEYSTROKE.  This  routine  reads  and  prints  a  keystroke  at  a 
given  position  in  the  screen.  It  updates  the  coluan  position 
according  to  the  key  type.  Refreshes  the  screen  if  CTRL/U  or 
CTRL/R  are  used,  deletes  a  character  if  the  DELETE  key  is 
used,  and  converts  lowercase  letters  to  uppercase. 

FORMAT 

KEYSTROKE  (PB,  KB,  VD,  ROW,  COLUMN,  KEY,  KEYTYPE) 

ARGUMENTS 

PB  -  input  integer;  specifies  the  pasteboard  identification. 

KB  -  input  Integer;  specifies  the  keyboard  identification. 

VD  .  input  integer;  specifies  the  read  display 
identification. 

ROV  -  input  integer;  represents  the  current  cursor  row 
position. 

COLUMN  -  input/output  Integer;  represents. the  current/updated 
coluan  position  of  the  cursor. 


KEY  ■  output  integer;  represents  the  ASCII  code  nuaber  of  the 
key. 
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KIT  TYPE  ■  output  integer;  represents  •  cod*  u<*d  to  identify 
the~key. 

3.  PRINT  DISPLAY.  This  routine  clears  a  specified  window  and 
prints  a  given  text  to  that  window. 

FORMAT 

PRINTDISPLAY  (VD,  LINE,  LINES) 

ARGUMENTS 

VO  «  input  integer;  specifies  the  display  identification. 

LINE  •  input  string  vector;  stores  the  lines  to  print. 

LINES  «  input  integer;  denotes  the  nunber  of  lines  to  print. 

4.  READ  DISPLAY.  This  routine  creates  a  display  of  given  vidth 
and  with  the  saee  height  as  the  aenu  display  to  read  the 
answers  and/or  commands  fron  the  user.  The  aenu  and  reading 
displays  are  scrolled  when  necessary.  For  aenu  questions 
(each  question  is  defined  in  the  text  file  by  an  asterisk  in 
the  first  column)  an  ansver  display  counter  is  created.  The 
bell  is  rung  once  to  attract  the  user's  attention. 

FORMAT 

READ  DISPLAY  (PB,  KB,  VD,  LINES,  LINE,  ROV  START, 
COLUMN  START,  WIDTH,  NO  OF  QUESTIONS,  LIHC  LINE,  "REPLY, 
COMMANBFLAG) 

ARGUMENTS 

PB  -  input  integer;  specifies  the  pasteboard  identification. 

KB  «  input  integer;  specifies  the  keyboard  Identification. 

VD  .  input  integer;  specifies  the  aenu  display 
Identification. 

LINES  -  input  Integer;  represents  the  nuaber  of  lines  in  the 
aenu. 

LINE  »  input  string  vector;  represents  the  text  lines  in  the 
aenu. 

ROV_ START  ■  input  integer;  represents  the  rov  position  for 
the~read  display. 

COLUMN_START  -  input  integer;  represents  the  column  position 
for  the  read  display. 


WIDTH  ■  input  integer;  denotes  the  width  of  the  read  display. 
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WO  OF  QUESTIONS  •  output  integer >  donotos  th«  nueber  of 
questions. 

LINKLIN1  •  output  intog*r  vector;  roprosonts  the  position  of 
the  questions  in  the  text  file. 

REPLY  *  output  strinf  vector;  stores  the  ansvers/coaswnds 
given  by  the  user. 

COMMANDFLAG  •  output  integer;  identifies  any  given  cotMand. 

5.  SCROLL  DISPLAY.  This  routine  scrolls  a  display,  vhen  the 

UF  aMW, . B6W- AJWOU ,  LINE- PEED  or  RETURN  key  are  used. 

FORMAT 

SCROLL  DISPLAY  (TYPE,  DIRECTION,  VD,  LINES,  LINE,  I  FLAG, 
ROVOLB,  ROW,  ROVFILE) 

ARGUMENTS 

TYPE  -  input  integer.  Possible  values  are:  0  to  scroll  the 
display,  and  1  to  read  fron  the  display  while  scrolling. 

DIRECTION  -  input  integer.  Possible  values  are:  -1  to 

scroll  up  the  display  by  one  rov,  and  1  to  scroll  down  the 
display  by  one  row. 

VD  -  input  integer;  specifies  the  display  identification. 

LINES  *  input  integer;  represents  the  nueber  of  lines. 

LINE  •  input  string  vector;  represents  the  text  lines. 

IFLAG  -  input  integer  vector;  Indicates  the  position  of 
non-eepty  lines. 

ROV  OLD  ■  input  Integer;  represents  the  previous  rov 
position. 

ROV  «  input  integer;  represents  the  nev  rov  position. 

ROV  FILE  -  output  integer;  represents  the  cursor  position 
vltiiin  the  file. 

6.  TEMPLATE.  This  routine  reads  and  prints  a  file  to  the  screen 
in  two  parts:  part  1  reads  and  prints  the  title  and  text  for 
the  Instructions  while  part  2  reads  and  prints  the  title  and 
text  for  the  wenu  or  help  vindov. 

FORMAT 

TEMPLATE  (INFILE,  VD1,  VD2,  LINES,  LINE) 


ARGUMENTS 
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INPILE  -  input  atring;  indicates  the  filename  to  be  read. 

VD1  •  input  integer;  specifies  the  menu  display 
identification. 

VD2  •  input  integer;  specifies  the  instructions  display 
identification. 

LINES  •  output  integer;  represents  the  number  of  lines  in  the 
menu. 

LINE  •  output  string  vector;  represents  the  eenu  text  lines. 
7.  VIEVTEXT.  This  routine  allows  a  text  to  be  vieved. 

FORMAT 

VIEVTEXT  (PBINFO,  IN  FILE,  LINE,  LINES,  COHMANDFLAG ) 
ARGUMENTS 

PB  INFO  ■  input  integer  vector;  specifies  the  display 
information. 

IN_FILE  -  input  string;  indicates  the  filename. 

LINE  ■  input  string  vector;  represents  the  eenu  text  lines  to 
be  vieved. 

LINES  >  output  integer;  represents  the  number  of  lines  in  the 
text. 

COHMANDFLAG  a  output  integer;  indicates  the  command  code  if 
one  vas~used. 


